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This  report  covers  completion  and  initial  demonstration  of  a 
Demonstration  Utility  Prototype  (DUP)  of  a stand-alone  Computer-based 
system  to  exercise  intelligence  analysts.  It  will  support  exercise  of 
the  intelligence  function  in  a realistic  fashion  in  accordance  with  DoD 
Instruction  5100.30. 
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SECTION  1. 


INTRODUCTION 


1.1  Background.  This  Final  Technical  Report  is  written  to  document  the 
results  of  the  contractual  effort  for  Contract  Number  F30602-77-C-0044, 
the  enhancement  of  the  Automated  Intelligence  Processes  Exercise  and  Review 
System  (AIPERS)  Demonstration  Utility  Prototype  (DUP) , for  the  period 
16  January  1977  to  15  January  J 978 . 

This  publication  is  the  fourth  in  a series  of  technical  reports  prepared 
by  INCO,  INC.,  which  defines  the  specifications  of  the  comp  Jurats  and 
functions  of  AIPERS.  The  initial  document  in  the  series  was  titled. 
Intelligence  Exercise  Generation  Concept,  1 April  1974.  The  second  document 
was  titled,  Exercise  Generation  Concept  Improvement:  Technical  Definitions 
and  a Development  Plan  for  an  Automated  Exercise  System,  30  June  1975,  and 
was  subsequently  published  as  RADC-TR-75-252 . With  this  documentation, 
the  feasibility  of  developing  and  automated  exercise  system  was  established 
and  a generalized  operational  concept  for  AIPERS  was  produced.  The  third 
document  was  titled,  Automated  Intelligence  Processes  Exercise  and  Review 
System,  Functional  Specif ications  and  Prototype  Development,  F30602-75-C-0283, 
Final  Report,  11  June  1976.  This  publication  presented  the  specifications 
of  the  components  of  the  DUP  exercise  system  which  were  developed  as  well 
as  the  functional  design  of  the  scenario  generation  subsystem. 

To  place  the  current  effort  in  context  of  past  endeavors,  a concise  review 
of  the  latter  follows.  In  the  previous  technical  reports,  INCO,  INC.: 

o Detailed  the  Indications  and  Warning  (I&W)  intelligence 
processes,  products  and  interfaces  with  other  functional 
areas  and  informational  resources. 

o Presented  the  objectives  of  exercises  and  exercise 
systems  derived  from  official  documentation. 

o Developed  methodologies  for  exercising  the  intelli- 
gence processes  on  a non-interference  basis. 

o Evolved  evaluation  criteria  for  an  automated  exercise 
generation  system  which  were  in  concert  with  the  de- 
fined objectives  of  exercises  and  exercise  systems. 

o Identified  the  body  of  state-of-the-art  technology 
which  is  applicable  to  the  design  and  structuring 
of  the  AIPERS. 

o Highlighted  the  critical  areas  of  design  work  for  research 
and  development. 

o Prepared  a detailed  developme.  plan  and  an  implement- 
ation schedule  for  the  exercise  system.  The  prototype 
programs  were  developed  and  they  were  documented. 


o Provided  functional  design  specifications  for  exercise 
control  and  tracking  functions  and  the  methodology  for 
performing  tracking.  These  functions  were  included  in  the 
exercise  prototype. 

o Articulated  initial  concepts  for  employing  decision  impact 
analysis  regarding  the  assessment  of  scenario  event  stim- 
ulated human  responses. 

o Accomplished  an  analysis  of  and  evolved  procedures  for 
exercise  operations  and  management  functions. 

o Provided  functional  design  specifications  for  scenario 
generation  with  automated  assists. 

1.2  Current  Status.  As  a result  of  the  development  performed  during 
this  contract,  two  subsystems  are  now  demonstrable.  These  are  the 
Scenario  Generator  and  the  Exercise  subsystems.  These  subsystems  are 
linked  via  the  Message  and  Resource  File  and  the  Message  Time  List  file.  An 
overview  of  the  system  is  shown  in  Figure  1-1.  The  three  modules  of  the 
Scenario  Generator  subsystem,  the  Library  Manager,  the  Scenario  Selection 
Processor,  and  the  Scenario  Formatter  were  written  during  this  contract 
period  from  specifications  developed  during  previous  contracts.  Enhance- 
ments were  made  to  the  modules  of  the  Exercise  Subsystem,  the  Exercise 
Control  Processor  and  the  Publisher,  to  provide  a more  efficient  and  stable 
system. 

Using  the  Scenario  Generator  subsystem,  the  system  manager  can  create  and 
update  a data  base  containing  categorized  messages  from  which  exercise 
scenarios  can  be  developed.  At  generation  time  the  messages  can  be  chosen 
selectively  (by  keyword)  and  added  to  the  exercise  scenario.  Other  exercise 
requirements,  such  as  message  time  tag,  resources,  and  anticipated  responses 
are  also  entered  into  the  scenario  data  files  for  access  during  the  exercise. 

The  Exercise  subsystem  has  the  capability  of  supporting  a variable  number 
of  user/analysts  terminals  along  with  a control  team  terminal.  These 
terminals  may  be  any  TTDL  supported  terminal  including  teletype  and  IBM  3270. 
In  testing  to  date,  an  exercise  with  two  user/analyst  terminals  has  been 
run,  demonstrating  this  multi-user/analyst  capability.  During  an  exercise, 
the  control  team  is  informed  of  the  status  via  a distribution  display  at 
the  terminal.  Using  this  status  information,  the  control  team  can  alter 
the  scenario  to  customize  the  scenario  to  the  conditions.  Tracking  infor- 
mation is  logged  detailing  all  actions  - system,  user/analyst,  or  control 
team  - during  the  exercise.  This  logged  data  is  to  be  used  as  the  input 
for  the  post-exercise  analysis,  when  it  is  developed. 

The  operation  and  maintenance  of  AIPERS  has  been  simplified  through  develop- 
ment of  command  streams.  A start-up  procedure  has  been  developed  where 
one  input  command  invokes  the  required  command  stream.  Similarly, 
procedures  have  been  developed  to  assemble,  task  build,  or  list  the  AIPERS 
modules . 


1-2 


1 


SSB  Release  III  TTDL  Software  was  incorporated  into  AIPERS.  This  software 
supports  IBM-3270  compatible  terminals,  and  permits  split  screen  control 
team  and/or  user/analyst  terminals. 

Through  overlaying  modules  and  re-distributing  the  functions  performed, 
memory  management  was  made  more  efficient  and  memory  dead-lock  avoided. 

Decision  analysis  software  was  developed  to  keep  the  control  team  informed 
of  the  status  of  the  exercise.  This  was  accomplished  by  displaying  perti- 
nent information  to  the  control  team  terminal. 

To  illustrate  the  new  capabilities  that  were  developed  during  this  contract, 
Figure  1-2  shows  a comparison  of  the  DUP  facilities  at  the  end  of  the 
previous  contract,  January  1977,  and  at  the  end  of  the  current  contract, 
January  1978. 
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Figure  1-2.  AIPERS  Comparison  (cont. 


SECTION  2.  RESPONSE  TO  THE  STATEMENT  OF  WORK 


2.1  Background.  The  SOW  for  this  contract  consists  of  five  tasks.  The 
work  performed  for  each  of  these  tasks  is  detailed  in  the  following  para- 
graphs . 

2.2  Subsystem  Specifications  for  the  Scenario  Generator  Subsystem.  These 
specifications  have  as  their  basis  the  Scenario  Generator  c-f  '.he  PUP,  using 
the  overall  program  flow  and  data  base  design.  The  extend*- < apabilities 
defined  for  the  Scenario  Generator  include  multi-mission  libraries,  a 
generalized  message  categorization  scheme,  message  routing  to  multiple 
arbitrary  destinations,  multiple  extended  user/analyst  resource  classifi- 
cations, definition  of  timed  system  responses  for  user/analyst  queries, 
mere  sophisticated  response  prediction  for  decision  analysis,  and  threshold 
criteria  definition  for  automatic  conditional  message  distribution. 

2.3  Enhancements  to  the  AIPERS  PUP.  Using  the  specifications  published 
under  the  previous  contract,  the  three  prototype  programs  of  the  Scenario 
Generator  subsystem  were  developed.  The  Library  Manager  is  a batch  program 
•which  maintains  the  Scenario  Message  Library.  The  program  processes  a card 

image  data  file  and  enters,  deletes,  or  categorizes  messages  in  the  library 
Summaries  of  the  library  contents  can  be  obtained  for  review  by  the  system 
manager . 

The  Scenario  Selection  Processor  is  the  first  of  a twe  phase  procedure 
to  create  the  data  files  for  the  scenario.  The  generation  team  member 
can  specify  a category  of  messages  which  is  of  interest.  This  set  of 
messages  is  then  made  available  for  display,  editing,  an-4  inclusion 
in  the  scenario.  If  the  Message  Library  contains  no  message  pertinent 
to  the  scenario,  a new  message  can  be  entered  interactively  into  the 
scenario  and  also  placed  in  the  Message  Library  for  subsequent  use. 

Another  feature  of  this  program  is  the  capability  to  modify  messages 
previously  added  to  the  scenario.  A hard  copy  of  the  scenario  exercise 
messages  may  be  requested. 

Processing  in  the  Scenario  Selection  Processor  is  designed  in  a structured 
format  with  total  control  of  the  processing  being  given  to  the  user.  At 
each  stage  of  processing  the  user  prompted  to  enter  the  next  function. 

A ’’aiid  command  may  be  entered  at  this  point  or  i f the  assistance  is 
required,  the  command  "HELP"  results  in  an  informational  display  being 
issued.  To  terminate  processing  at  a given  level  of  execution,  the  command 
"STOP"  is  entered. 

The  Scenario  Formatter  performs  the  served  phase  function  in  developing  the 
files  for  the  scenario.  Resources  whirl  the  analyst  may  access  are  entered. 
Messages  are  time  tagged  and  the  anti  ed  response  array  and  quety 

responses  are  entered.  Using  procedures:  similar  to  those  used  in  the  Scenario 
Selection  Processor,  the  user  controls  the  functions.  When  prompted  lor  a 
command,  the  user  may  enter  a processing  command,  a request  for  assistance 
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("HELP"),  or  a request  for  termination  ("STOP").  A hard  copy  of  the  infor- 
mation used  during  the  scenario  may  be  requested. 

In  the  Exercise  subsystem,  the  software  was  restructured  to  make  it  more 
flexible  and  efficient.  The  memory  requirement  was  reduced  by  combining 
the  Scenario  Processor  functions  into  the  Tracker/Publisher  and  Exercise 
Control  Processor  and  eliminating  the  Scenario  Processor  as  a separate 
module. 

Under  the  restructured  exercise  system  procedure,  the  Exercise  Control 
Processor  (ECP)  has  two  functions.  First,  the  ECP  performs  the  message 
scheduling  based  upon  the  time  tag  for  the  message  saved  in  the  Message 
Time  List  file.  For  each  message  the  Publisher  is  called  to  issue  the 
message.  Additionally,  the  Control  Team  functions,  such  as  adding  or 
deleting  messages  or  altering  time  tags,  are  performed. 

The  Publisher/Tracker  module  has  several  functions  under  the  current 
DUP.  The  Publisher  displays  the  message  text  on  every  active  user/analyst 
terminal.  Then  the  message  log  file  is  updated  to  reflect  the  current 
message  displayed.  The  decision  analysis  distribution  display  on  the 
control  team  terminal  is  updated.  Finally,  each  event  that  occurs  during 
an  exercise  is  recorded  on  the  hard  copy  logging  device  and  the  tracking 
log  file  to  permit  post-exercise  evaluation. 

The  Analyst  Function  Processor  required  only  minor  modifications.  This 
processor  performs  the  user/analyst  functions  including  reviewing  messages 
and  requesting  information  from  or  querying  resources.  For  each  user/analyst 
active  during  the  exercise,  a separate  copy  of  this  processor  is  executed. 

Overlay  structures  were  created  for  the  Exercise  Control  Processor,  the 
Analyst  Functions  Processor,  and  the  On-Line  Editor.  These  overlays 
resulted  in  a reduction  of  memory  which  aided  in  resolving  memory  manage- 
ment conflicts. 

The  interface  with  TTDL  was  upgraded  to  incorporate  SSB  Release  III  TTDL 
Software.  Features  in  this  new  release  permitted  the  use  of  IBM  3270 
compatible  terminals  (RAYTHEON  P.TS'lOO). 

2.4  Installation  of  the  AIPERS  DUP  at  RADC.  This  task  was  modified  by 
an  engineering  change  proposal  and  a substitute  task  was  performed.  The 
revised  task  was  to  research  the  interface  of  AIPERS  and  SSB.  The  resultant 
functional  description  is  included  as  Appendix  A of  this  report. 

2,3.  Perform  AIPERS  DUP  Demonstrations.  During  the  term  of  this  contract, 
three  formal  demonstrations  were  given,  occurring  in  the  months  of  June 
and  October  1977,  and  January  1978.  The  project  engineer,  Pat  Langendorf, 
was  present  at  all  of  these  sessions. 
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During  these  demonstrations  the  various  features  of  AIPERS  were  presented. 

A complete  26  minute,  15  message  exercise,  supporting  two  user/analysts 
in  TTDL  teletype  mode  and  a control  team  was  run  to  completion.  Additionally 
an  exercise  was  run  demonstrating  the  capability  of  multiple  user/analysts 
utilising  split  screen  IBM  3270  compatible  terminals.  The  features  of 
the  Scenario  Generation  subsystem  were  also  demonstrated.  These  included 
the  message  library  creation  and  maintenance,  and  the  message  selection 
and  preparation  for  the  exercise. 

2.6  Computer  Program  Delivery.  At  the  termination  of  this  contract, 
a copy  of  all  software  related  to  AIPERS  was  delivered  to  RADC.  This 
included  source,  object,  and  task  image  of  the  AIPERS  modules  and  the  task 
images  of  the  support  software.  Additionally,  the  procedures  which  were 
developed  to  perform  assemblies,  listings,  and  task  building  were  delivered. 
The  form  of  these  deliverables  consisted  of  a magnetic  tape  containing  a 
preserve  of  a disk  pack  and  hard  copy  listings  of  the  source  image  files. 

2.7  Deliverables.  In  accordance  with  Contract  Data  Requirements  List, 
there  are  five  deliverables  associated  with  this  contract. 

A0Q1  - R&D  Status  Reports.  The  status  reports  were  submitted  to  RADC 
monthly.  These  reports  reflected  the  contract  performance  during  the 
period. 

I 

A002  - Subsystem  Specifications.  The  specifications  for  the  Scenario 
Generation  Subsystem  were  presented  in  the  report.  These  specifications 
outlined  a system  which  was  an  outgrowth  of  the  AIPERS  DVP  Scenario  Gener- 
ation Subsystem. 

A003  - Users  Manual.  This  document  detailed  the  user  interface  during  an 
exercise.  The  control  team  functions,  the  analyst  functions,  and  the  on-line 
editor  functions  were  defined. 

A004  - Computer  Program  Documentation.  This  document  provided  maintenance 
information  for  the  six  modules  of  the  AIPERS  DUP . Program  descriptions, 
variable  definitions,  and  flow  charts  were  included  for  each  program. 

A005  - Technical  Report.  The  accomplishments,  status,  and  potential  future 
goals  of  the  AIPERS  project  are  discussed  in  this  document. 


SECTION  3.  FUTURE  GOALS 


3.1  General.  The  research  and  development  work  accomplished  in  the  previous 
and  current  AIPERS  contracts  has  established  a base  for  proceeding  toward 

an  operational  AIPERS/SSB  (Standard  Software  Base)  exercise  system.  SSB  is 
an  operational  system  and  work  leading  toward  an  extended  exercise  system 
could  be  based  primarily  upon  the  extension  of  AIPERS  facilities. 

The  current  AIPERS  is  displayed  in  Figure  3-1.  The  major  ne;.  r r pabilities 
which  could  be  added  are  an  AIPERS  enhanced  Decision  Analyst's  . -ipability, 
automated  aids  to  post-exercise  evaluation  and  integration  within  the  SSB 
environment.  The  potential  areas  for  development  are  described  in  the  follow- 
ing sections. 

3.2  Decision  Analysis  Capability.  The  decision  analysis  capability  would 
permit  comparison  of  an  analyst  response  to  main  event  messages  with  a pre- 
positioned response  array  which  has  values  assigned  to  each  response.  Invalid 
or  unique  responses  would  get  the  immediate  attention  of  the  control  team. 

This  decision  analysis  capability  would  also  provide  answers  to  analyst  queries 
directed  to  agencies  not  participating  in  the  exercise.  These  answers  would 

be  inserted  in  the  scenario  processor  and  scheduled  to  arrive  in  the  analyst 
queue  at  times  comparable  to  those  of  actual  response  conditions. 

3.3  Automated  Post-Exercise  Evaluation  Aids.  The  automated  aids  to  post- 
exercise evaluation  would  provide  summary  data  of  system  actions,  decision 
analysis  details  and  isolated  actions  related  to  specific  main  scenario 
events.  This  data  would  be  provided  in  summary  form  for  the  evaluation  team. 
Figure  3-2  portrays  the  inputs  which  would  lead  to  the  formulation  of  summary 
data.  The  summaries  could  save  many  hours  of  referencing  notes  and  painfully 
reconstructing  the  analyst  handling  of  specific  events. 

3, A Upgrade  AIPERS.  The  modification  of  current  AIPERS  modules  (analyst, 
control  team,  and  publisher)  would  be  directed  primarily  to  the  use  of  AIPERS 
with  the  U-1652  terminal.  Architecture  of  the  extended  AIPERS  including  the 
potential  capabilities  described  in  Section  3.2  and  3.3  is  portrayed  in 
Figure  3-3. 

3.5  AIPERS/SSB  Analyst  Station.  The  development  of  the  AIPERS/SSB  Analyst 
Station  would  consist  of  the  adaptation  of  AIPERS  to  the  SSB  environment. 

Figure  3-4  shows  an  overview  of  the  system.  The  functional  description  for 
the  system  is  contained  in  Appendix  A of  this  report. 

3.6  System  Documentation.  Documentation  essential  to  an  exercise  planner 
and  to  the  AIPERS/SSB  is  envisioned.  The  exercise  Planner’s  Guide  would  be 
designed  as  a comprehensive  manual  adapt;, die  for  all  intelligence  exercise 
planning.  It  would  assist  in: 

o Establishing  exercise  goals 

o Scenario  development 
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ure  3-1.  Current  AIPERS  System 


Figure  3-2.  Post-Exercise  Evaluation 


o 

2 

M < W 

CJ  < < 
< Q cfl 


S w b 

S*  o « 

3 

S w « 

H W (O 

d w m 

a as  -j 


Figure  3-3.  Modernized  AIPERS  System  Summary 


Figure  3-4.  AIPERS/SSB  System  Overview 


o 


Specifying  main  scenario  events 
o Evaluation  methodology 

o Exercise  validation. 

The  emphasis  in  this  guide  would  be  on  defining  what  is  to  be  evaluated  and 
the  consideration  of  human  factors. 

A Scenario  Generation  User's  Manual  would  explain  the  terminal  procedures  for 
using  the  automated  aids,  accessing  the  libraries  used  in  scenario  generation, 
and  examining  data  from  past  exercise  procedures. 

The  existing  AIPERS  User's  Manual  for  the  DUP  would  be  enhanced  to  bring  it 
into  line  with  the  extended  AIPERS.  Finally,  a System  Manager's  Guide  would 
be  developed  for  use  and  maintenance  of  the  data  system  - the  message 
library,  the  command  descriptions  and  all  information  necessary  to  provide 
exercise  computer  support  for  scenario  generation,  exercising  and  post- 
exercising  evaluation. 

3.7  Multiple  Scenario  Capability.  To  provide  this  enhancement,  four  areas 
of  development  would  be  required.  These  are  to  develop  a multi-mission 
scenario  capability,  to  revise  and  complete  the  existing  I&W  scenario,  to 
initiate  an  S&T  Library,  and  to  create  software  for  the  multi-mission  intelli- 
gence scenario  capability.  The  multi-mission  scenario  capability  would  permit 
the  exercise  to  involve  both  I&W  and  S&T  analysts  simultaneously.  On  future 
efforts,  targeting  and  collection  analysis  could  also  be  included  as 
legitimate  exercise  functions. 

3.8  "Read  Only"  Areas  and  Exercise  Isolation.  The  investigation  of  security 
aspects  of  using  ("read  only")  actual  operational  data  bases  and  communica- 
tions in  an  exercise  environment  should  be  conducted.  An  associated  area 
would  be  to  investigate  the  processes  required  to  isolate  the  exercise  message 
traffic  from  operational  traffic  even  though  the  same  data  bases  and  communica- 
tions are  used. 

3.9  Summary.  The  areas  described  reflect  that  improvements  and  enhancements 
to  AIPERS  would  comprise  a continuous  cycle.  As  depicted  in  Figure  3-5,  each 
demonstration  of  AIPERS  could  result  in  the  identification  of  shortfalls  and 
improvements  necessary  to  bring  the  automated  exercise  system  closer  to 
actual  intelligence  operations.  Looking  forward  in  exercise  development, 
this  technique  would  combine  a major  advancement  in  the  system  cycle  with 
significant  initiatives  into  the  operational  exercise  environment. 

The  matrix  of  Figure  3-6  shows  the  functional  interrelationships  which  would 
take  place  between  the  enhanced  AIPERS  and  the  users,  and  within  AIPERS  itself. 
The  chart  identifies  information/data  flow  between  nodes  as  well  as  the  major 
system/subsystem  exchanges.  The  system/subsystem  nodes  are  shown  along  the 
diagonal  (blocks  1 through  11).  The  information  or  data  that  is  provided  or 
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3-5.  AIPERS  Improvement  Cycle 


Modernized  AIPERS  System/Flow  Matrix 
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received  are  shown  along  the  horizontal  or  vertical  axes.  A block  along  the 
horizontal  is  an  output  from  a node;  a block  along  the  vertical  is  an  input. 
For  example,  the  block  labeled  1-3  shows  that  the  Exercise  Director  issues 
an  exercise  directive  to  the  Control  Team  and,  in  turn,  the  Control  Team 
closes  the  informational  loop  by  providing  reports  to  the  Exercise  Director. 
The  chart  identifies  the  tasks  that  are  performed  but  not  how  they  are 
accomplished.  Some  of  the  data  flow  is  still  accomplished  manually  based 
on  generated  data  which  is  manipulated  by  the  user  and  then  reentered  either 
back  to  the  sending  module  or  to  another  based  on  the  type  of  information/ 
data. 


SECTION  4. 


SYSTEM/SOFTWARE  DESIGN 


4.1  Overview.  General  improvements  and  additions  to  the  AIPERS  Exercise 
Subsystem  were  made  during  the  current  contract.  The  improvements  were 
in  the  form  of  modifications  to  existing  modules  as  well  as  architectural 
changes.  The  basis  for  the  improvements  was  providing  greater  stability 
and  optimizing  performance.  The  main  addition  to  the  exercise  subsystem 
was  the  decision  analysis  capability.  A summary  of  improvements  is  given 
below: 

o Modified  necessary  modules  to  use  RSX-11D  overlay 
capability. 

o Installed  SSB  release  III  TTDL  and  performed  custom 
system  generation  to  reduce  memory  requirements  and 
limit  memory  fragmentation. 

o Enhanced  control  processor  to  include  message  scheduling 
thereby  avoiding  access/update  contention  problems. 

o Enhanced  tracker  (Publisher)  to  perform  message 
publication  as  well  as  decision  analysis. 

o Modified  AIPERS  text  editor  to  improve  operating 
efficiency. 

4.2  Overlay  Construction.  Overlay  segments  have  been  constructed  from 
the  Analysts  Functions  Processor  (AFP)  and  the  Exercise  Control  Processor 
(ECP) . The  basic  approach  has  been  to  construct  three  levels  of  segments 
from  each  main  program  and  two  for  the  co-tree,  i.e.,  EDITOR.  These  levels 
contain  the  following  information  (see  also  Figure  4-1). 

Main  Tree 

Level  0 Single  Segment 

Control  module,  file  info,  EDITOR  data,  error  routines  and  displays, 
ICM  subroutines,  and  other  subroutines  required  for  both  initializa- 
tion and  processing. 

Level  1 Two  Segments 

Initialization  module,  select  menu  display,  processing  and  termination 
modules,  and  function  subroutines. 

Level  2 Multiple  Segments 

Functions  modules,  and  function  displays. 
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Main  Tree  Level  0 


Control  Module 


Main  Tree  Level  2 

Analyst  Functions 
Segments 


Co-tree  Level  1 

Editing  Functions 
Segments 


Figure  4-1.  Memory  Diagram 


Co-Tree 


Level  0 Single  Segment 

Editing  text  buffers,  EDITOR  processing  module,  error  handling,  and 
editing  subroutines. 

Level  1 Multiple  Segments 

EDITOR  functions  modules  and  function  displays. 

The  DEC  task  builder  manual  contains  a discussion  of  multiple  tree  structures. 
A co-tree  is  used  because  several  lower  level  segments  of  the  main  tree 
reference  a module  which  is  itself  segmented,  i.e.,  EDITOR.  The  root  seg- 
ment of  the  co-tree  will  remain  resident,  once  loaded.  This  approach 
reduces  disk  storage  requirements  and  load  time  as  well  as  permitting  a 
simpler  overlay  description. 

At  task  build  all  external  modules  with  the  exception  of  the  TTDL  IV  sub- 
routines, are  appended  to  the  root  segment  of  the  main  tree.  This  linkage 
occurs  because  the  major  software  products  are  single  user,  e.g.,  TIMS,  or 
are  referenced  through  ICM  via  an  interface  module,  e.g.,  TTDL  AIM.  In 
the  case  of  single  user  modules,  a single  reference  appends  the  entire  module, 
and  all  subsequent  references  in  further  levels  are  directed  to  the  single 
occurrence  modules  and,  consequently,  ISC  file  handling  modules  are  appended. 

A similar  situation  occurs  with  TTDL.  However,  the  concatenated  module 
embodies  only  entry  points. 

The  purpose  of  overlay  construction  is,  of  course,  memory  space  reduction. 
Level  1 was  used  to  overlay  initialization  code  which,  by  definition,  is 
needed  only  at  task  startup.  The  tasks  have  been  further  partitioned  on 
the  basis  of  operator  selected  functions,  since  the  programs  were  written 
with  functions  as  the  fundamental  modular  unit.  No  attempt  was  made  to 
further  reduce  space  by  selective  subroutine  segment  loading.  There  are 
some  possibilities  for  such  reductions,  e.g.,  PSECT  SGDTG.  All  support 
subroutines  are  maintained  in  Level  1 in  the  main  tree  and  Level  0 in  the 
co-tree. 

Overlays  were  constructed  using  program  sections,  i.e.,  PSECT,  instead  of 
object  modules  for  several  reasons.  PSECT  structuring  permits  a single 
consolidated  source  listing  and  is  easier  to  examine,  correct,  and  assemble. 
One  disadvantage,  not  readily  apparent,  is  that  program  sections  are  not 
autoloadable.  Consequently,  all  loading  was  performed  manually,  i.e.  , via 
calls  to  $LOAD.  Some  modifications,  in  addition  to  program  section  place- 
ment, were  required  to  assure  that  functions  were  not  referencing  code  in 
parallel  functions. 

As  a result  of  segmentation  and  a reduction  in  file  buffers,  the  analyst 
processor  was  reduced  in  size  from  65,000  to  56,000  octal . A substantial 
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reduction  in  the  control  processor  was,  also,  obtained.  There  is  no  per- 
formance degradation  because  of  the  already  slow  nature  of  menu  selection. 

4.3  AIPERS  Memory  Requirements.  Because  of  the  continuing  memory  space 
problems  with  AIPERS,  a thorough  memory  requirements  analysis  was  performed 
resulting  in  a revised  system  generation  phase  I file  and  modifications 
to  the  exercise  initialization  system. 

The  following  modifications  were  made  to  the  Standard  RSX-11D  Sysgen 
Phase  I file. 

1.  Creation  of  separate  16K  TTDL  partition  for  transient  TTDL  tasks. 
Sysgen  Statement:  PAR  = TTDL,, 1000, S 

2.  Reduction  of  System  Node  Pool. 

Sysgen  Statement:  SCOM  = ,400,100 

3.  Installation  of  the  overlay  version  of  the  disk  auxiliary 
control  processor. 

Sysgen  Statement:  INS  = GEN, [11,1]FCP 

The  TTDL  partition  is  used  for  all  transient  TTDL  tasks.  The  terminal 
tasks,  TTDL6T  andTTDL6I,  and  TTDL  Common  Area,  TTDLRE,  are  still  run  in 
the  GEN  partition,  since  these  tasks  are  resident  throughout  the  exercise. 
The  use  of  this  partition  avoids  GEN  partition  fragmentation  without  allo- 
cating the  30K  memory  required  to  fix  all  the  TTDL  transient  tasks.  TTDL 
is  not  reentrant  and  all  tasks  are  serially  invoked  via  the  applications 
interface  module  (AIM).  The  worst  case  TTDL  memory  requirements  can  be 
computed  by  summing  the  sizes  of  the  four  largest  TTDL  tasks,  since  there 
are  four  AIPERS  tasks,  in  dual  analyst  configuration,  and,  consequently, 
four  interface  modules.  In  practice,  it  seems  that  no  more  than  three 
TTDL  tasks  are  simultaneously  resident.  For  this  reason  the  size  of  the 
partition  was  determined  by  summing  only  the  sizes  of  the  three  largest 
TTDL  tasks. 

Another  advantage  of  the  TTDL  partition  is  that  the  TTDL  generation  task, 
TTDLGEN,  and  the  command  processor,  AT.,  may  be  run  in  the  TTDL  partition 
to  avoid  fragmentation  in  the  GEN  partition.  This  task  is  only  resident  at 
system  initialization,  but  invokes  the  TTDL  terminal  task  and,  consequently, 
the  common  areas,  all  of  which  are  resident  throughout  the  exercise. 

The  system  node  pool  was  reduced  to  an  average  exercise  level  of  100  nodes 
to  reduce  the  size  of  the  executive. 

The  use  of  the  overlay  version  of  the  F11ACP  task  resulted  in  savings  of 
approximately  3K  words,  at  the  cost  of  slower  disk  access.  It  should  be 
noted  that  the  auxiliary  control  processor  was  fixed  in  memory  immediately 
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after  phase  II  of  Sysgen,  and  prior  to  loading  any  handlers.  Since  all 
unnecessary  handlers  are  removed  by  the  exercise  initialization  procedure 
and  the  di  rocessor  must  remain  throughout  the  exercise,  fixing  the 
auxiliary  dx^x  processor  avoids  fragmentation  problems. 

One  modification  was  made  in  the  intertask  communication  module,  ICM,  to 
reduce  the  number  of  internal  nodes  from  128.  to  64,,  resulting  in  a IK 
savings.  The  node  pool  size  is  determined  .by  a conditional  assembly  vari- 
able, TPNDN,  and  is  based  on  maximum  simultaneous  services  requests 
and  dynamic  allocations. 

The  resulting  memory  requirements  for  each  system  and  support  software 
component  are  described  in  Figure  4-2.  Almost  84K  of  the  124K  memory  is 
used  leaving  approximately  40K  for  AIPERS  tasks.  Figure  4-2  details  the 
memory  requirements  for  AIPERS  on  a task  basis. 

As  AIPERS  expands  there  are  several  methods  by  which  memory  requirements 
can  be  decreased.  Task  size  can  be  reduced  by  overlay  techniques  and  use 
of  the  TTDL  display  library.  Task  management  can  be  effectively  handled 
via  checkpointing. 

4.4  Exercise  Subsystem  Design.  Some  problems  were  alleviated  by  a modified 
design.  The  problems  were  excessive  memory  requirements  and  occasional 
timing  problems,  resulting  in  incorrect  scenario  message  publication. 

More  specifically,  there  were  contention  discrepancies  in  the  access  and 
updating  of  the  message  time  list  file,  which  drives  the  scenario.  To 
take  advantage  of  the  scheduling  capability  of  RSX,  the  scenario  processor 
schedules  the  "next"  message  immediately  after  the  current  one  is  published, 
i.e.,  the  scenario  publishing  is  event  driven  rather  than  discrete  time 
interval  driven.  In  the  case  where  the  control  processor  is  requested  to 
modify  the  "next"  message  either  by  actually  changing  the  time,  or  adding 
an  immediate  message  or  deleting  the  "next"  message,  there  is  extensive 
programming  required  to  provide  the  necessary  communication  to  assure  that 
the  next  message  is  indeed  the  one  that  the  control  team  requested.  This 
orocessing  is  much  easier  to  handle  if  the  communication  is  not  task-to-task , 
but  within  a single  task.  So,  it  was  appropriate  to  incorporate  the  Scenario 
Scheduling  function  into  the  exercise  control  processor. 

Some  other  concerns  are  the  following.  Although  the  scenario  processor 
is  event  driven,  an  internal  one  second  "clock"  was  maintained  by  using  RSX 
clock  services.  This  clock  was  actually  used  to  publish  messages.  Since 
very  often  the  scenario  processor  may  be  checkpointed  to  disk,  this  clock 
loses  about  one  second  per  minute.  If  instead  the  RSX  task  scheduling 
services  are  used,  the  time  loss  and  checkpointing  overhpad  could  be  reduced. 


BASIC  SYSTEM 


Decimal 

Component  Size  (words) 


RSX11D  16. IK 
SYSRES  4 . IK 
Disk  Handler  1.0K 
F11ACP  (overlayed  version)  3. OK 
Teletype  Handler  2.8K 
MCR  Partition  1.3K 

27. 2K 


SUPPORT  SOFTWARE 


Component 

ICM- Intertask  Communication 
Module 

BFRTSK  - Buffer  Task 
TTDLRE  - Common  Area 
TTDL6T  - Teletype  Terminal 
Task 

TTDL6I  - IBM  3270  Terminal 
Task 

TTDL  Partition 
IBM  3270  Handler 


Decimal 
Size  (words) 


4.3K 
16.  OK 
12.  OK 

4.  IK 

2.5K 
16.  OK 
4.  OK 
56. 9K 


AIPERS 


Component 


Decimal 
Size  (words) 


Analyst  processor  (multiple) 
Control  processor 
Publisher 


11. 5K 
13. 2K 
11. 2K 
35. 9K 


Figure  4-2.  System  Memory  Requirements 
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The  only  other  function  of  the  scenario  processor  is  message  publishing. 

It  was  reasonable  to  incorporate  this  function  into  another  task  to  reduce 
system  overhead, e . g. , redundant  file  access  routines.  The  logical  choice 
would  seem  to  be  the  exercise  control  processor.  However,  since  it  con- 
stantly maintains  a function  menu,  TTDL  would  need  to  be  reentrant  and  it 
is  not.  A similar  situation  exists  with  the  analyst  processor.  Tl.° 
tracker,  however,  publishes  via  asynchronous  flashes  and  can  queue  and 
publish  the  scenario  messages  without  difficulty. 

In  summary,  the  following  design  enhancements  were  incorporated  into 
AIPERS : 

1.  Incorporate  scenario  scheduling  into  the  control  processor. 

2.  Include  scenario  publishing  into  the  Tracker  (Publisher). 

4.5  Text  Editor  Improvements.  In  addition  to  overlaying  the  text  editor 
to  reduce  the  size  of  all  tasks  which  use  the  editor,  two  other  improve- 
ments were  made.  First,  key  data  movement  and  search  routines,  e.g., 
SECMOV,  were  optimized  to  increase  the  speed  of  editing.  Second,  the 
control  menu  was  made  optional  as  in  the  scenario  generation  software.  So, 
unless  the  user  requests  menu  operation,  he  can  use  abbreviations  follow- 
ing the  command  request  prompt. 


4.6  Decision  Analysis.  Decision  analysis  information  consists  of  two 
Response  Distributions  for  each  of  up  to  three  analysts.  One  distribution 
contains  a cumulative  exercise  distribution;  the  other  a floating  five 
(5)  message  average.  Rather  than  actual  counts,  the  distribution  is 
listed  in  percentiles.  In  addition,  the  screen  area  contains  the  real 
and  simulated  times  and  a recent  events  list  containing  the  last  ten  (10) 
actions  (control,  or  any  user/ analyst ) with  the  associated  simulated  time. 

All  of  this  information  is  maintained  on  an  alternate  control  team  screen 
area  by  the  publisher  module.  Other  additions  to  the  publisher  include 
publishing  the  response  arrays,  and  maintaining  a sequential  system  action 
file  on  disk. 

Two  sources  could  be  used  to  determine  to  which  message  a response  is  attri- 
butable. The  "acknowledge  message"  user  analyst  function  is  not  used,  since 
all  analyst  functions  request  prompting  message  ID.  The  actual  time  sequence 
is  not  used  since  the  user  analyst  may  not  have  viewed  the  incoming  message 
immediately  on  arrival  in  teletype  terminal  operation. 

The  system  action  file  contains  identically  the  contents  of  the  service 
request  blocks  passed  to  the  publisher  module  as  well  as  the  elapsed  time. 
Decision  analysis  data  is  thus  contained  implicitly  rather  than  explicitly. 
The  contents  of  each  service  request  block  is  listed  in  AIPERS  Interim 
Program  Documentation  (1976). 
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SECTION  5.  SCENARIO  GENERATION  SUBSYSTEM 

5.1  Background.  This  subsystem  was  developed  during  this  contract  period 
to  provide  automated  assists  in  the  creation  of  exercise  scenarios.  To 
facilitate  this  capability,  a message  library  is  maintained  to  provide  a 
source  of  message  categorized  by  content.  The  scenario  generation  team  may 
Select  messages  from  the  library  either  explicitly  or  by  category  and 
modify  the  message  as  desired  prior  to  inclusion  in  the  exercise  scenario. 

Prior  to  using  the  Scenario  Generation  Subsystem,  a preliminary  manual 
‘ procedure  must  be  performed.  The  goal  of  the  exercise  scenario  is  chosen, 

and  then  the  appropriate  message  topics  are  specified  so  that  the  message 
library  may  be  scanned  for  appropriate  messages. 

5.2  User  Interface.  The  subsystem  consists  of  three  modules  communicating 
through  data  files.  The  structure  of  the  subsystem  is  illustrated  in  Figure 
5-1.  The  generation  team  inputs  requests  via  data  file  or  CRT  as  indicated. 

5.2.1  Library  Manager.  The  Library  Manager  module  serves  two  functions. 

. First,  maintenance  of  the  Scenario  Message  Library  is  performed.  Messages 

can  be  added,  deleted,  or  reclassified  as  needed.  The  second  function  is  to 
produce  hard  copy  listings  of  the  library  contents  to  enable  manual  review 
by  the  generation  team  so  that  appropriate  messages  can  be  selected  (in  the 
Scenario  Selection  Processor)  or  if  no  messages  are  available,  a new  message 
can  be  added  to  the  library. 

The  Library  Manager  is  a batch  mode  program.  A set  of  five  control  cards 
* is  used  to  specify  the  desired  processing.  The  control  card  format  is 

. ‘ shown  in  Figure  5-2. 

Where  applicable,  directives  follow  the  control  card  to  specify  additional 
information  required  for  processing.  The  function  is  terminated  by  a 
/END/  terminator  card. 

In  Figures  5-3  through  5-6  the  directives  for  the  functions  are  shown.  Note 
that  REVIEW  has  no  directives. 

5.2.2  Scenario  Selection  Processor.  The  Scenario  Selection  Processor  is 
the  module  where  messages  are  extracted  from  the  Scenario  Message  Library 
either  explicitly  by  message  ID  or  implicitly  by  category  keyword.  The 
selected  messages  are  placed  in  the  Message  and  Resource  File  for  inclusion 
in  the  exercise  scenario. 

The  program  is  designed  so  that  the  user  is  prompted  for  Input  at  nested 
levels.  At  each  level,  the  user  can  obtain  a display  of  valid  input  commands 
by  entering  the  command  "HELP".  The  comand  "STOP"  terminates  processing 
at  the  current  level  and  brings  the  user  lo  the  next  higher  level. 
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Card  Columns 

Field  Contents 

Function  to  be  Performed 

1-6 

AD DM S3 

Add  messages  to  the  library 

1-6 

REFILE 

Refile  messages  under  dif- 
ferent categories 

1-6 

DELETE 

Delete  messages  from  the 
library 

1-6 

REVIEW 

Review  messages  filed  under 
category  "IV-a-01"  of  KWINDX 

1-6 

SUMARY 

Prepare  a summary  of  current 
message  library  contents 

Figure  5-2.  LIBMGR  Control  Card  Format 


Message 

Field  Column 

Card  No. 

Numbers 

Field  Contents 

1 

1-72 

FM  designator 

2 

1-60 

RE  designator 

3 

1-60 

REF  designator 

61-74 

DTG  designator 

4 

1-5 

"/EOH/"  (End  of  Header 

5 

1-80 

Message  text  line  as  it  will 
appear  on  the  screen) 

Note:  Each  new  part  must  be 

• 

indented  five  spaces.  Maximum  of  20 

• 

cards  per  part.  Maximum  message  text 
length  is  approximately  4000  char. 

M 

1-5 

"/EOM/"  (End  of  message) 

M+l 

1-3 

Roman  Numeral  Category 

5 

Alphabetic  subcategory 

7-8 

Numeric  subcateogry 

; 

Note:  Maximum  of  10  category  cards. 

N 

1-5 

"/EOC/"  (End  of  Categories) 

Figure  5-3.  ADDMSG 

Input  Format  for  Scenario  Library  Messages 
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CARD 

COLUMNS 


CONTENTS 


PURPOSE 


1-3 

5-14 

15-18 

20 

22-23 

ADD 

Message  ID 

"To"  Category  Numeral 
Alphabetic  Subcategory 
Numeric  Subcategory 

Add  a message  reference  to 
the  specified  category. 

1-3 

5-14 

16-18 

20 

22-23 

DEL 

Message  ID 

"From"  Category  Numeral 
Alphabetic  Subcategory 
Numeric  Subcategory 

Delete  a message  reference 
from  the  specified 
category. 

1-3 

5-14 

16-18 

20 

22-23 

25-27 

29 

31-32 

MOV 

Message  ID 

"From"  Category  Numeral 
Alphabetic  Subcategory 
Numeric  Subcategory 
"To"  Category  Numeral 
Alphabetic  Subcategory 
Numeric  Subcategory 

Move  a message  reference 
from  one  category  to 
another. 

i 


Figure  5-4.  REFILE  Function  Input  Card  Format 
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CARD 

COLUMNS 


CONTENTS 


PURPOSE 


14-16 

18 

20-21 

23-25 

27 

29-30 


12-14 


16-25 


27-36 


KWINDX 

COUNT  or  MSGID 

First  Category  Numeral 
Alphabetic  Subcategory 
Numeric  Subcategory 

Last  Category  Numeral 
Alphabetic  Subcategory 
Numeric  Subcategory 

File  specification 

List  count  of  ID's  or  individual 
message  ID's 

Optional  first  category 
to  be  reported.  (If  blank, 
list  starts  with  category 
I-a-01) 

Optional  last  category 
to  be  reported.  (If  blank, 
list  stops  with  category 
IV-a-01. ) 

MSGLIB 

File  specification 

RE  or  MSG 

List  RE  header  line  or  entire 

message 

CAT 

List  categories  which  reference 

message  (optional) 

First  Message  ID 

Optional  first  message  to  be  re- 

ported.  (Default=AES-000001 . ) 

Last  Message  ID 

Optional  last  message  to  be  re- 

ported.  (Default=AES=999999. ) 

Figure  5-6.  SUMMARY  Function  Input  Card  Format. 
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Initially,  the  user  specifies  the  name  of  the  Scenario  Message  Library  and 
Message  and  Resource  File.  The  prompt  is: 

MSGLIB  - MSG  & RES  = 

(NEW/ OLD)  = 

Permitting  this  specification  allows  the  processing  of  multiple  libraries. 
The  NEW/OLD  specification  permits  the  start  of  a new  exercise  data  file 
(NEW)  or  the  continuation  of  building  onto  an  existing  exercise  data  file 
(OLD) . 

•The  next  prompt  begins  the  prompt  message  which  is  repetitive.  This  is  the 
highest  level  prompt  and  if  "STOP"  is  entered,  the  program  is  terminated. 

INPUT  SOURCE  = 

The  acceptable  responses  are 

1.  SCNMSG  - Scenario  Message  Library 

2.  MSGRES  - Message  and  Resource  File 

3.  NEW  - Interactive  via  Terminal 

4.  HELP  - List  This  Menu 

5.  STOP  - Terminate  This  Program 

6.  LIST  n,k  - List  the  Scenario  (message  ID's  n thru  k) 

For  each  of  these  commands,  an  appropriate  prompt  sequence  is  performed. 
Each  sequence  is  described  in  the  following  paragraphs. 

1.  SCNMSG  - To  access  the  Scenario  Message  Library  (MSGLIB),  the 
user  is  prompted  to  specify  the  three  levels  of  keys  used  to  categorize 
Messages.  The  prompt  is: 

KEY  n » where  n=l,2,3. 

The  acceptable  responses: 

o The  actual  key  for  the  level 

o "MSGID"  whereby  the  input  of  keys  is  terminated  and  the 
prompting  for  the  message  ID  (6  digits)  for  specific 
messages  is  begun. 

o "STOP"  whereby  Message  Library  processing  is  terminated. 

o "NEXT"  prompt  for  key  1 of  next  message  set. 

If  all  three  keys  are  input  to  specify  a category,  a display  of  all 
messages  in  the  category  set  is  output.  The  user  is  then  asked  to  select 
the  message  to  be  processed.  The  prompt  is: 

MSGID  - 
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The  acceptable  responses  are: 

o The  actual  6 digit  key 

o "NEXT"  references  next  message  in  the  list.  (It 

should  be  noted  that  if  the  user  reached  this  point 
by  entering  "MSGID"  to  a prompt  for  a key,  there 
will  be  no  "NEXT"  message.  Each  message  reference 
must  be  by  6 digit  key.) 

o "HELP”  whereby  all  message  ID  numbers  in  the 

category  are  displayed.  The  valid  commands  are 
also  displayed. 

o "STOP"  whereby  processing  messages  in  the 

category  is  terminated  and  the  first  key  of  the 
next  category  is  solicited. 

As  each  message  is  selected  and  retrieved,  the  user  can  edit,  review,  and 
add  messages  to  the  MSGRES.  The  prompt  is: 

FUNCTION  = 


The  acceptable  responses  are: 

o REVIEW  - Review  Message  Text 

o EDIT  - Edit  the  Message 

o ADD  - Add  Message  to  MSGRES 

o HELP  - List  this  Menu 

o STOP  - Terminate  Processing  This  Message 

REVIEW  results  in  the  message  being  displayed  at  the  terminal. 


EDIT  places  the  user  in  edit  mode  where  modifications  can  be  made  to  the 
text  prior  to  adding  to  the  message  library. 

ADD  results  in  the  current  message  (with  modifications)  being  added  to  the 
Message  and  Resource  file.  The  message  ID  is  generated.  The  user  is 
then  asked  if  the  message  is  to  be  added  to  the  scenario  message  library 
in  the  "NO  CATEGORY"  classif ication.  The  prompt  message  is: 

SAVE  IN  SCENARIO  MESSAGE  LIBRARY  (YES  OR  NO)? 


HELP  results  in  the  command  menu  being  displayed. 


STOP  terminates  processing  this  message.  The  prompt  for  the  input  of  the 
next  message  ID  is  displayed. 


2.  MSGRES  - When  accessing  the  Message  and  Resource  File  (MSGRES) 
the  6-digit  message  ID  number  is  used  as  the  key.  The  prompt  is: 

MSGID  = 

where  the  user  inputs  the  6-digit  key.  (This  value  was  assigned  when 
placing  in  the  MSGRES  file  and  it  may  not  be  the  same  as  the  number  assigned 
to  the  message  in  the  MSGLIB  Library.) 

Optionally,  the  user  may  enter  "NEXT"  and  the  next  message  is  accessed. 
(Access  is  in  the  order  that  messages  were  placed  in  the  MSGRES  file.) 

"STOP"  terminates  input  from  MSGRES.  As  each  message  is  selected,  the  user 
can  perform  editing  and  review  functions.  The  prompt  is: 

FUNCTION  = 

The  acceptable  responses  are: 

o REVIEW  - Review  Message  Text 

o EDIT  - Edit  the  Message 

o REPLACE-  Replace  Message 

o DELETE  - Delete  Message 

o HELP  - List  this  Menu 

o STOP  - Terminate  Processing  this  Message 

REVIEW  results  in  the  message  being  displayed  at  the  terminal. 

EDIT  places  the  user  in  the  edit  mode. 

REPLACE  results  in  the  message  being  processed  replacing  the  text  in  the 
library  under  the  same  message  ID  number.  If  any  editing  was  performed, 
the  user  is  asked  if  the  message  is  to  be  saved  in  MSGLIB  in  the  "NO  CLASS- 
IFICATION" classification.  The  prompt  is: 

SAVE  IN  SCENARIO  MESSAGE  LIBRARY  (YES  OR  NO)? 

DELETE  removes  the  message  from  the  MSGRES  file. 

HELP  lists  the  menu  of  available  commands. 

STOP  terminates  processing  this  message. 


3.  NEW  - New  messages  can  be  entered  interactively  through  the 
terminal.  (Note  that  library  maintenance  functions  on  the  Scenario  Message 
Library  can  be  performed  using  the  library  manager  module.) 

The  user  is  prompted  with  a request  for  a command. 

FUNCTION  = 

The  acceptable  responses  are: 


o 

EDIT 

- Create/Edit  Message  Text 

o 

ADD 

- Add  Message  to  Library 

0 

HELP 

- List  this  Menu 

o 

STOP 

- Terminate  Processing  New  Messages 

EDIT  provides  all  of  the  capabilities  to  create  and  edit  a message. 

ADD  results  in  the  message  being  added  to  MSGRES . After  adding  the  message 
to  MSGRES  the  user  is  asked  if  the  message  is  to  be  added  to  MSGLIB.  The 
prompt  is: 

SAVE  IN  SCENARIO  MESSAGE  LIBRARY  (YES  OR  NO)? 

HELP  results  in  the  command  selection  menu  being  displayed. 

STOP  terminates  processing  new  messages. 

4.  HELP  displays  the  available  commands 

5.  STOP  terminates  the  program. 

6.  LIST  produces  a hard  copy  listing  of  the  Message  and  Resource 
File.  If  start  and  stop  message  ID  numbers  are  specified  (n,k)  all  messages 
in  the  file  that  were  created  after  n and  before  k,  as  well  as  message  n 
and  k,  will  be  listed. 

5.?. 3 Scenario  Formatter.  This  processor  is  used  to  add  additional  infor- 
mation into  the  Message  Resource  File  for  use  during  the  exercise.  These 
items  include  the  eight  variable  resources,  message  time  tags,  and  message 
anticipated  response  arrays.  Additionally,  messages  entered  into  the  Message 
and  Resource  File  may  be  reviewed  or  modified. 

The  prompt  sequence  and  user  responses  are  as  follows: 

DEFINE  RESOURCES  (RES)  OR  TIME  TAGS  AND  RESPONSE  ARRAY  (TAGS): 
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1.  RES  - In  this  mode  the  generation  team  member  defines  resources 
for  the  scenario.  The  prompt  is: 


NAME  = name  TYPE  =■  t MENU  //  = mm 

NAME  - A 1-13  character  resource  name  or  "STOP”  to  indicate  end  of  resource 
definition  or  "HELP"  to  request  a display  of  the  current  resources. 

TYPE  - The  resource  type.  The  valid  values  are: 

Q - Query  the  data  base 

A - Access  a source  reference  (such  as  a map) 

R - Request  information  from  other  personnel  or  agency 

MENU  ft  - An  integer  whose  value  is  5-12  corresponding  to  the  menu  numbers 
in  the  analyst  function  menu. 

2.  TAGS  - In  this  mode,  the  information  required  on  a per  message 
basis  is  entered  (e.g.,  time  tags  and  response  arrays). 

The  prompt  input  defines  the  message  ID 

ENTER  MESSAGE  ID  OR  "STOP"  AES  - XXXXXX 

where  XXXXXX  is  the  message  ID  number  or  "STOP"  to  specify  the  BLDMRS 
is  to  be  terminated. 

The  user  next  has  a choice  from  a seven  function  selection  menu.  This  menu 
is  displayed  only  in  response  to  the  "HELP"  function.  The  prompt  for  an 
input  function  is: 

FUNCTION:  To  which  one  of  the  following  may  be  input: 

REVIEW,  EDIT,  TAG,  PREDICT,  NEXT,  HELP,  STOP. 

These  keywords  refer  to  the  possible  actions  which  are: 

o REVIEW  - REVIEW  MESSAGE  CONTENTS 

o EDIT  - EDIT  MESSAGE  CONTENTS 

o TAG  - ASSIGN  TIME  TAG 

o PREDICT  - ANTICIPATED  RESPONSE  ARRAY 

o NEXT  - NEXT  MESSAGE 

o HELP  - LIST  THIS  MENU 

o STOP  - TERMINATE  PROGRAM 
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The  function  performed  by  each  command  is  described  below: 

o REVIEW  and  EDIT  branch  to  the  EDITOR  to  perform  the  function 
desired . 

o TAG  results  in  the  prompt  for  the  time  tag. 

ENTER  TIME  TAG  - ELAPSED  TIME  FROM  EXERCISE  START  (HH:MM:SS) 

o PREDICT  is  the  command  for  entering  the  anticipated 
response  array.  The  user  is  prompted  with: 

ENTER:  to  specify  the  function  desired.  These  functions  are: 

LIST  nn  - display  response  nn  (5<=r<=12) 
nn  + m - assign  a value  of  + to  response  nn 
(-6<=m<=+6) . 

STOP  - terminate  BLDMRS 

HELP  - display  all  possible  responses. 

o NEXT  results  in  the  program  returning  the  ENTER  MESSAGE  ID  AES  - 
prompt  described  above. 

o HELP  results  in  the  selection  menu  described  above  being 
displayed . 

o STOP  causes  BLDMRS  to  terminate.  Just  prior  to  BLDMRS  ter- 
mination, the  last  prompt  is  issued.  DO  YOU  WANT  HARD  COPY 
OF  SCENARIO  (YES  OR  NO):  If  "YES",  a copy  is  printed  on  a 
hard  copy  device. 

5.3  Data  Files . There  are  four  data  files  used  in  the  Scenario  Generation 
Subsystem.  These  files  provide  the  communication  between  the  subsystem 
modules  as  shown  in  Figure  5-1. 

5.3.1  Scenario  Message  Library.  This  library  contains  categorized 
messages  which  can  be  treated  as  the  source  of  messages  used  in  an  exercise 
The  classification  is  such  that  all  messages  belonging  to  a category,  (e.g. 
LAND-ECONOMIC-TRADE),  may  be  accessed  by  keyword  (e.g.,  I-A-01)  in  the 
Scenario  Selection  Processor.  As  new  messages  are  developed  to  meet  the 
requirements  of  an  exercise,  these  messages  can  be  categorized  and  stored 
for  use  in  later  scenario  generations.  As  mentioned  earlier,  messages  are 
entered  into  this  library  using  the  Library  Manager  program. 

5.3.2  Keyword  Index  File.  The  Keyword  Index  File  contains  the  pointers 
tc  the  individual  messages  in  the  Scenario  Message  category.  These 
pointers  are  created  and  maintained  by  the  Library  Manager  program  as  the 
Scenario  Message  Library  is  being  updated. 
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5.3.3  Message  and  Resource  File.  Messages  are  entered  into  this  file 
using  the  Scenario  Selection  Processor.  The  message  text  is  obtained  either 
from  the  Scenario  Message  Library  or  interactively  during  a selection 
session. 

Additional  items  required  for  the  exercise  are  entered  into  this  file  via 
the  Scenario  Formatter  program.  These  items  include  the  eight  resources 
which  are  used  throughout  the  exercise  and  the  response  array  and  replies  for 
queryable  resources  unique  to  each  message. 

5.3.4  Message  Time  List  File.  This  file  is  created  along  with  the  Message 
and  Resource  File.  For  each  message  in  the  Message  and  Resource  File,  a 
corresponding  record  exists  in  the  Message  Time  List  File.  This  record 
contains  the  time  (elapsed  seconds  since  exercise  start)  at  which  the 
message  is  to  be  published.  Status  about  the  message  (e.g.,  if  it  was 
sent,  if  it  was  altered  by  the  control  team)  is  also  maintained  in  the 
record  corresponding  to  the  Message  and  Resource  File  record. 

5.4  Operational  Considerations.  The  three  modules  of  the  subsystem  may  be 
run  repeatedly  in  a semi-random  order.  Figure  5-7  schematically  shows  an 
example  of  how  the  subsystem  may  be  used.  Effectively  after  each  program 
is  executed,  the  option  is  either  to  terminate  the  subsystem  processing, 
re-run  the  same  program,  or  run  a previous  program.  The  final  termination 
of  the  subsystem  would  occur  when  the  Message  and  Resource  File  has  all 

of  the  information  required  to  execute  an  exercise. 

To  assist  the  generation  team  in  determining  the  source  of  scenario  messages, 
audit  trail  information  is  maintained.  When  the  Selection  Worksheet  is  printed 
in  the  Scenario  Selection  Processor,  the  source  of  the  messages  is  printed  in 
addition  to  the  message  text.  The  message  source  is  either  the  message  ID 
from  the  Message  Library  or  "NEW"  indicating  that  the  message  was  entered 
interactively  during  a selection  session. 
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NEXT  STEP 


RUN 

SCENARIO 

FORMATTER 
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APPENDIX  A 

AIPERS/SSB  FUNCTIONAL  DESCRIPTION 


SECTION  1 GENERAL 


1.1  Purpose  of  the  Functional  Description. 

The  Functional  Description  for  the  Automated  Intelligence  Processes 
Exercise  and  Review  System  (AIPERS)  F30602- 77-C-0044  as  interfaced  with  the 
Standard  Software  Base  (SSB)  is  written  to  provide: 

a.  The  system  requirements  to  be  satisfied  which  will  serve  as  a 

basis  for  user/developer  understanding. 

b.  Information  on  performance  constraints,  preliminary  design, 

and  user  impact,  including  fixed  and  continuing  costs. 

c.  A basis  for  the  system  implementation  and  system  tests. 

1.2  Project  References. 

a . Demonstration  Utility  Prototype  of  Automated  Intelligence 
Processes  E&ercise  and  Review  System,  Interim  Program  Docu- 
mentation, INCO,  INC.,  March  1976,  Unclassified. 

b . Automated  Intelligence  Processes  Exercise  and  Review  System, 
Functional  Specif ications  and  Prototype  Development,  Final 
Report , INCO,  INC.,  June  1976,  Unclassified. 

c.  AIPERS  as  an  SSB  Training  Mechanism,  Technical  Memo  1089/9, 

INCO,  INC.,  June  1977,  Unclassified. 

d.  AIPERS  Exercise  System  Design,  Technical  Memo  1089/8,  INCO, 

INC.,  June  1977,  Unclassified. 

e.  AIPERS  Memory  Requirement,  Technical  Memo  1089/10,  INCO,  INC., 
July  1977,  Unclassified. 

f.  AIPERS  Overlay  Structure,  Technical  Memo  1089/3,  INCO,  INC., 
March  1977,  Unclassified. 

g.  Common  Users  Baseline  for  the  Intelligence  Community:  Overview, 
INCO,  INC.,  September  1977,  Unclassif led . 

h.  SSB  Installation  Manual,  INCO,  INC.,  October  1977,  Unclassified. 


i.  SSB  Programmers  Manual,  INCO,  INC.,  October  1977,  Unclassified.' 
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]L>  AIPERS  Program  Documentation,  INCO,  INC.,  January  1978, 
Unclassified. 

n.  Subsystem  Specifications  for  Scenario  Generation,  INCO,  INC 
December  1977,  Unclassified. 
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SECTION  2 SYSTEM  SUMMARY 


2.1  AIPERS  Background. 

In  response  to  DoD  directives  requiring  intelligence  units  to  be 
exercised  as  other  military  units  and  in  cooperation  with  Rome  Air  Develop- 
ment Center,  INCO  has  developed  the  Atuomated  Intelligence  Processes  Exercise 
and  Review  System  (AIPERS)  Demonstration  Utility  Prototype  (DUP) . This 
initial  exercise  system  is  aimed  at  training  analysts  by  simulating  crisis 
situati»»s,  meeting  one  of  the  three  objectives  of  the  operational  AIPERS 
system.  These  objectives  are  to  provide  analyst  training  in  both  crisis 
management  and  operating  procedures,  evaluate  analyst  procedures,  and  determine 
the  adequacy  of  ADP  support,  specifically  examining  excessive  time  delays 
and  adequacy  of  facilities.  In  addition  to  the  capability  provided  by 
the  actual  exercise  system,  automated  procedures  have  been  developed  to  aid 
in  scenario  generation  and  will  be  developed  to  aid  in  post-exercise  evaluation. 

The  overall  implementation  objective  of  the  current  AIPERS  effort 
is  to  establish  an  enhanced  exercise  capability  which  will  serve  as  demonstra- 
tion software  and  provide  a solid  basis  for  proceeding  toward  an  operational 
system.  This  project  will  provide  the  software  basis  for  development 
toward  an  operational  design  specifications  for  incorporating  AIPERS  into 
SSB . 

Specific  objectives  of  the  current  AIPERS  contract  are  to  perform 
the  following  tasks. 

o Incorporate  automated  assists  for  scenario  generation  in  the 
DUP. 


Commence  the  automation  of  features  of  decision  impact 
analysis  in  the  control  function  of  the  DUP. 

Develop  system  specifications  for  the  scenario  generation 
subsystem  to  be  included  in  the  operational  AIPERS, 
specifically  addressing  message  library  management, 
scenario  generation  and  scenario  construction. 

Develop  a functional  description  for  an  AIPERS/SSB  analyst 
station. 


o Conduct  frequent  demonstrations  of  the  AIPERS  DUP  at  INCO. 
SSB  Background. 


In  1973  and  1974  the  Directorate  of  Intelligence  Data  Management, 
Air  Force  Intelligence  Service,  Headquarters  United  States  Air  Force  (AFIS/ 
IND) , conducted  a survey  of  USAF  Intelligence  Data  Handling  System  (IDHS) 
modernization  programs.  The  USAF  programs  involved  implementation  of  the 
AN/GYQ-21(V)  system  as  either  a stand-alone,  front-end,  or  communications 


processor.  All  program  development  planning  featured  some  form. of  systems 
software,  many  of  which  were  common  to  one  another.  To  eliminate  redundancy 
in  the  various  development  efforts  and  to  realize  both  cost  avoidances  and 
cost  savings,  AFIS/IND  formulated  a program  to  develop  a Standard  Software 
Base  (SSB)  which  would  provide:  common  system  software  for  AN/GYQ-21(V) 
users,  basic  communications  networking  software  capabilities,  a series  of 
file  handling  services,  terminal  device  interface  capabilities,  and  a 
series  of  software  gateways  for  access  to  external  files,  data  bases, 
systems,  and  networks. 

The  overall  objective  of  the  Standard  Software  Base  (SSB)  is  to 
provide  a common  inventory  of  modular  software  tools  which  will  enable 
AN/GYQ-21(V)  system  users  to  quickly  and  effectively  develop  and  implement 
data  communications  interfaces  and  to  enhance  the  implementation  of  unique 
command/agency/activity  applications . 

2.3  Objectives. 

The  implementation  objective  of  this  effort  is  to  merge  the  AIPERS 
exercise  subsystem  with  the  Standard  Software  Base. 

The  resulting  system  will  meet  the  following  two  objectives: 

a.  Provide  crisis  management  training. 

b.  Serve  as  a tool  in  terminal  operation  and  procedure  training 

for  SSB. 

A primary  objective  of  any  exercise  system  design  is  to  work  within 
the  analyst  environment  using  the  usual  terminal  procedures,  formats,  data 
bases  and  communications  links.  Complicating  the  achievement  cf  this  object- 
ive is  the  requirement  to  avoid  interference  with  other  analysts  at  work  on 
their  operational  tasks.  This  requirement  equates  to  isolating  the  exercis- 
ing analyst (s)  so  that  exercise  output  and  input  messages  do  not  get  into 
the  operational  distribution  systems.  In  order  to  effectively  evaluate 
current  procedures  and  provide  analyst  training,  the  testing  environment 
must  be  one  with  which  the  analyst  is  familiar  or  needs  to  be  familiar. 

Hence,  it  is  assumed  that  the  analyst  interface,  i.e.,  terminal  procedures,  is 
left  intact. 

This  development  effort  will  result  in  the  demonstration  of  an 
automated  exercise  and  training  system  within  the  JCS  exercise  system.  This 
automated  exercise  system  will  provide  greater  flexibility  in  adapting  to 
various  software  systems  and  will  speed  up  the  evaluation  of  exercise 
results.  In  addition,  this  exercise  system  will  allow  the  user  to  perform 
a comprehensive  check-out  of  their  I&W  functions  and  to  evaluate  the  ade- 
quacy and  thoroughness  of  the  activities  that  are  carried  out  by  intelligence 
analysts . 


Figure  A-l.  AIPERS  System/ Flow  Matrix 


Existing  Methods  and  Procedures. 


2.4 


The  following  paragraphs  describe  the  organizational/personnel 
responsibilities,  equipment  situation,  and  high-level  system  Inputs  and 
Outputs . 


a.  AIPERS  Perscnne ’ / Sys tern  Data  Flow. 

The  matrix  of  Figure  A-l  shows  the  functional  interrelation- 
ships between  the  enhanced  AIPERS  and  the  users,  and  within  the 
AIPERS  itself.  The  chart  identifies  information/datr  flow  between 
nodes  as  well  as  the  major  system/subsystem  exchanges.  The  system/ 
subsystem  nodes  are  shown  along  the  diagonal  (blocks  1 through  11). 
The  information  or  data  that  is  provided  or  received  are  shown  along 
the  horizontal  or  vertical  axes.  A block  along  the  horizontal 
is  an  output  from  a node;  a block  along  the  vertical  is  an  input. 

For  example,  the  block  labeled  1-3  shows  that  the  Exercise  Director 
issues  an  exercise  directive  to  the  Control  Team  and,  in  turn, 
the  Control  Team  closes  the  informational  loop  by  providing  reports 
to  the  Exercise  Director.  The  chart  identifies  the  tasks  that 
are  performed  but  not  how  they  are  accomplished.  Some  of  the 
data  flow  is  still  accomplished  manually  based  on  generated 
data  which  is  manipulated  by  the  user  and  then  reentered  either 
back  to  the  sending  module  or  to  another  based  on  the  type  of 
information/ data . 

A software  overview  of  AIPERS  is  presented  in  Figure  A-2. 

Each  set  of  solid  lines  (block)  outlines  a function,  or  subsystem, 
which  is  performed  off-line  with  respect  to  the  other  blocks. 
Collectively  the  Scenario  Generation  block  and  library  maintenance 
block  are  referred  to  as  the  Scenario  Generation  or  pre-exercise 
subsystem.  The  exercise  processing  block  is,  also,  referred 
to  as  the  exercise  subsystem. 

Each  block  contains  a small  square  in  a lower  corner  which 
indicates  the  support  software  required.  Rectangles  are  used  to 
denote  modules;  disks  for  files  and  the  standard  symbols  for 
peripherals.  Data  flows  are  indicated  by  directed  arrows. 

Further  detail  may  be  obtained  by  reviewing  AIPERS  program  docu- 
mentation and  AIPERS  related  technical  memoranda. 

b.  SSB  Personnel/System  Data  Flow. 

The  key  personnel  associated  with  the  SSB  system  are  the 
user/analysts . In  addition,  SSB  has  published  literature  for  a 
system  operator  and  site  programmers. 

The  selection  of  the  RSX-11D  operating  system  as  the  community 
standard  relieved  the  problem  of  providing  a common  operating 
system  to  AN/GYQ-21(V)  users.  By  retaining  unchanged  the  vendor 
released  versions  of  RSX-11D,  only  sub-executive  level  modules  wore 
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' required  to  extend  its  capability  to  accommodate  development  of 

communications  networking,  terminal  device  interface,  and  file 
handling  software.  Three  major  subsystems  are  evolving  within  the 
confines  of  the  Standard  Software  Base  to  provide  these  essential 
elements  of  common  systems  software.  Rome  Air  Development  Center's 
Terminal  Oriented  Support  System  (TOSS)  was  used  as  the  basis  for 
the  communications  networking  and  terminal  device  interface  soft- 
ware. The  Storage  and  Retrieval  Processor  (SARP)  was  developed 
to  provide  the  file  handling  services. 

SSB  provides  a common  inventory  of  modular  software  tools 
which  enable  system  users  to  quickly  and  effectively  develop  and 
implement  data  communication  interfaces  and  to  enhance  the  imple- 
mentation of  site  applications.  Because  of  the  modular  design, 
only  those  components  directly  required  by  a given  site  will  need 
to  be  installed  at  that  site. 

The  Release  3 configuration  of  SSB  consists  of  four  major 
software  components.  They  are  the  Terminal  Transparent  Display 
Group  (TTDL) , the  Applications  Modules  Group,  the  Gateway  Manager 
, . Group,  and  the  Gateways  Group.  It  enables  the  denigner/programmer  to 

develop  simple  or  complex  input  and  output  displays  for  a virtual 
terminal  display  screen.  TTDL's  software  adapts  the  virtual 
terminal's  characteristics  to  those  of  any  physical  terminal  on 
which  a terminal  application  is  run.  The  Applications  Modules 
Group  provides  the  I/O  terminal  user  with  a variety  of  message 
handling  functions  such  as  logging  on  to  access  the  system,  build- 
ing and  transmitting  messages,  and  receiving  and  reviewing  message 
' traffic.  The  Gateway  Manager  Group  interfaces  all  SSB  application 

. ' software  with  non-applications  software.  It  provides  centralized 

traffic  control  for  the  system  and  separates  communj cations , 
terminal,  and  system  software  from  each  other.  This  separation 
makes  possible  the  interface  witli  other  site-dependent  systems 
such  as  CATIS.  The  Gateway  Manager  concept  protects  against 
unauthorized  access  to  SSB  capabilities  and  files,  and  also 
provides  for  automatic  journalization  of  incoming  and  outgoing 
traffic  in  the  system.  The  Gateways  Group  provides  the  actual 
gateways,  or  interfaces,  between  SSB  and  external  systems  such 
as  Al'TODIN,  CATIS,  and  the  DIA  on-line  system  (DIAOLS)  . Figure  A-3 
shows  the  relationships  between  each  group,  as  well  as  peripherals 
and  users. 

c.  Equipment  Required  and  Available. 

This  section  defines  the  minimum  hardware/software  configur- 
ation required  to  support  SSB  Release  3. 

The  following  hardware  requirements  are  the  minimum  within 
which  SSB  will  operate: 
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Figure  A-3.  SSB  Release  3 System/Subsystems 


AN/GYQ-21 (V) 


BR  1569  or  DL-11  interface  to  Western  Union  PTC  or  Analytics 
TLC  for  AUTODIN 

Teletype-compatible  terminals  (minimum  of  1) 

RP-04  disk  drive  (minimum  of  1) 

TU16  tape  drive  (optional) 

CR11  card  reader  or  similar  device  (optional) 

AIPERS  requires  the  same  configuration  since  it  now  uses 
SSB  software,  particularly  TTDL.  A detailed  discussion  of  the 
memory  requirements  is  presented  in  technical  memorandum,  "AIPERS 
Memory  Requirements." 

2.5  Proposed  Methods  and  Procedures 

It  is  proposed  that  AIPERS  be  integrated  into  S3E  as  an  external 
gateway.  As  a gateway  messages  could  be  routed  to  any  destination;  analysts 
via  the  terminal  gateway  or  communications  networks  (or  simulators)  via 
communication  gateways.  Figure  A-4  depicts  the  AIPERS/SSB  architecture. 

Since  the  SSB  user  interface  is  being  maintained,  the  analyst 
processor  will  be  superseded  by  the  host  user  modules  which  will  communicate 
with  the  exercise  control  gateway.  The  control  gateway  will  perform  the 
scenario  scheduling  and  control  functions  handling.  The  remainder  of  SSB 
will  also  be  left  intact.  No  modifications  need  be  made  to  scenario  gener- 
ation modules. 

2.5.1  Summary  of  Improvements 

The  following  paragraphs  will  summarize  improvements  in  terms  of 
new  capabilities  and  improved  capabilities  and  timeliness. 

a.  Capabilities 

The  primary  capability  which  will  be  added  to  the  SSB  system 
is  the  ability  to  simulate  message  traffic.  Associated  with  this 
capability  are  the  functions  of  message  file  construction  and 
sequencing,  dynamic  message  file  changes,  and  activity  logging. 

The  functional  capabilities  resulting  will  be  the  ability 
to  train  analysts  in  crisis  management  procedures,  to  train 
analysts  in  terminal  procedures  and  to  provide  perfomance  data 
on  the  host  software  system  in  the  case  where  a central  routing 
structure  is  used  in  the  system,  e.g.,  SSB,  WICS. 
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Figure  A—'*.  AIPERS/SSB  System  Overview 


b.  Timeliness 

Timeliness  will  be  improved  in  terms  of  analyst  evaluation 

and  man-machine  dialogue.  There  will  be  some  impact  on  computer 

response  times  due  to  increased  workload,  but  this  will  be  minimal. 

2.5.2  Summary  of  Impacts 

The  following  paragraphs  will  describe  impacts. 

2. 5. 2.1  Equipment  Impacts 

No  additional  equipment  will  be  required. 

2. 5. 2. 2 Software  Impacts 

Software  impacts  will  depend  upon  the  amount  of  site-dependent 
additions  to  the  SSB  system.  AIPERS  will  require  relatively  little 
processor  time  and  can  reside  in  shareable  memory. 

Three  SSB  files  will  need  to  be  augmented.  These  are  the  SSB 
system  common  (C0MF1L) , the  Gateway  Options  File  (GOTFIL) ■ and  the  Routing 
Information  file  (RIFFIL) . In  addition,  if  new  users  are  being  added,  the 
user  file  (USRFIL)  must  be  modified. 

To  support  AIPERS  as  a gateway,  additional  occurrences  of  two 
SSB  data  structures  are  required.  These  are  a network  characteristics 
table  (NCT)  and  a Route  Reference  Table  (RRT).  Complete  descriptions  of 
these  structues  and  the  associated  sysgen  macros  are  contained  in  the  SSB 
Installation  Manual. 

The  GOTFIL  contains  gateway  specific  information  which  must  be 
both  obtained  and  displayed  to  the  user  analyst.  Any  information  which 
is  not  to  be  treated  as  text  must  be  obtained  via  modifications  to  the 
GOTFIL.  This  file  is  gateway-dependent  and  not  generally  modified  by  site 
installation.  Consequently,  constructing  an  additional  option  table  will 
require  review  of  SSB  technical  documentation. 

The  RIFFIL  is  an  installation-dependent  file  which  contains 
essential  routing  information  accessible  via  user  names.  These  names  are 
standard  to  all  users. 

At  present  no  initialization  will  be  required  for  AIPERS.  If 
inittalization  is  required,  this  can  be  accomplished  via  the  SSB  module, 
TISINT. 


Minor  modifications  will  be  required  to  the  AIPERS  control 
processor  in  particular,  the  ISSUE  routine.  Rather  than  retrieving  a 
message  and  passing  it  to  the  Publisher  module  via  buffer  task,  the  message 
will  have  to  be  constructed  as  a TCF  message  using  SSB  global  routines  and 
the  message  distribution  module  will  have  to  be  notified. 
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The  publisher  will  have  to  be  modified  to  act  as  a send  gateway. 

In  addition  some  message  interpretation  logic  should  be  added  to  provide  a 
decision  analysis  capability.  As  a send  gateway,  the  publisher  will  communi- 
cate with  the  message  distribution  module  and  the  accounting  module 
(TISAFM) . 

All  intertask  communication  is  via  ICM  macros.  The  two  principal 
functions  are  request  module  (RTMR)  and  return  status  (RSTA) . 

2. 5. 2. 3 Organizational  Impacts 

No  additional  personnel  will  be  required  for  either  system  but 
the  proposed  system  will  require  all  the  personnel  of  each  of  the  two  systems. 

2. 5. 2. 4 Operational  Impacts 

No  major  operational  impacts  are  foreseen  in  terms  of  processing. 

An  exercise  may  be  run  on-line  with  other  legitimate  users  provided  that  the 
trainee  does  not  interfere  with  concurrent  traffic.  Off-line  exercise 
procedures,  such  as  scenario  generation  may  be  performed  at  any  time  as  SSB 
applications . 

2. 3. 2. 5 Developmental  Impacts 

No  user  developmental  impact  is  foreseen. 

2.6  Expected  Limitations 

Some  limitations  are  inherent  in  the  present  exercise  system.  Some 
facets  of  the  analyst's  routine  will  have  to  be  simulated  and  consequently 
may  not  refelct  real  world  situations. 

Since  only  the  end  product  i.e.,  finished  intelligence  messages, 
are  received  by  AIPERS,  no  evaluation  or  assistance  can  be  provided  with 
respect  to  terminal  procedures.  Possibly,  some  conclusions  can  be  drawn 
from  the  elapsed  time  required. 

Since. the  analyst  responses  to  a given  scenario  are  in  the  form  of 
messages,  decision  analysis  and  post  exercise  evaluation  will  probably  be 
only  partially  automated. 

As  mentioned  earlier,  if  standard  network  synonyms  are  to  be 
used  and  still  have  concurrent  exercising  and  intelligence  gathering,  then 
the  RIFFIL  entries  must  be  local  to  a given  user. 


SECTION  3.  DETAILED  CHARACTERISTICS 


3.1  Specific  Performance  Requirements 

Since  the  system  is  being  constructed  rather  than  improved,  the 
requirements  for  the  AIPERS/SSB  system  are  of  a qualitative  rather  than 
quantitative  nature.  The  requirement  is  to  provide  an  exercise  system  with 
sufficient  capability  to  provide  analyst  training  in  routine  terminal  pro- 
cedures as  well  as  crisis  management.  In  addition  this  exercise  system  should 
be  constructed  in  a modular  fashion  to  permit  straightforward  coupling 
with  other  major  software  systems. 

More  specific  requirements  are  listed  below. 

a.  The  SSB  site  should  be  able  to  simultaneously  conduct  exer- 
cises and  routine  operations. 

b.  The  AIPERS  system  must  reside  in  shareable  memory  to  permit 
normal  site  dependent  applications  to  co-exist. 

c.  The  AIPERS  system  must  not  substantially  increase  overhead. 

3.1.1  Accuracy  and  Validity 

The  following  is  a summary  of  the  accuracy  and  validity  require- 
ments . 

a.  The  control  processor  must  not  permit  messages  to  be  forwarded 
if  they  are  being  modified  in  any  fashion. 

b.  A time  granularity  of  no  more  than  one  (1)  minute  is  permitted 
with  respect  to  message  scheduling. 

c.  No  textual  examination  of  ad  hoc  messages  will  be  performed, 
e.g.,  for  code  words. 

d.  Decision  analysis  information  will  be  based  solely  on  textual 
message  interpretation,  e.g.,  keywords. 

e.  All  log  entries  are  to  have  posting  time  from  exercise  start 
to  the  nearest  second. 

3.1.2  Timing 

a.  Throughput 

Ninety  percent  of  forwarded  messages  must  have  a processing 
delay  of  10  seconds  or  less. 
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b. 


Priorities 


Two  priorities  must  be  assigned  with  respect  to  the  SSB 
system.  The  exercise  control  processor  (includes  message  schedul- 
ing) should  be  assigned  a priority  greater  than  the  publisher 
module  (includes  message  interpretation  and  decision  analysis) 
but  less  than  the  operational  SSB  system. 

c.  Interleaving  Requirements 

AIPERS  memory  management  is  largely  based  on  overlay  struc- 
tures. It  is  appropriate  to  continue  this  approach  since  disk 
activity  is  presently  not  a constraint  whereas  available  memory 
is  somewhat  limited.  Although  the  control  processor  is  time- 
driven  (via  asynchronous  system  traps),  the  time  frame  is  minutes. 
So,  checkpointing  overhead  is  not  a factor. 

3.2  System  Functions 

In  addition  to  the  capability  provided  presently  by  the  SSB 
system,  the  following  major  AIPERS  functions  will  be  added. 

a.  Scenario  Generation  Subsystem 

This  subsystem  is  used  to  construct  or  retrieve  messages, 
time  sequence  the  messages  and  provide  prediction  data  for  decision 
analysis.  The  subsystem  will  remain  unmodified.  The  definition 
of  analyst  resources  will  be  superfluous  since  the  SSB  system  inher- 
ently defines  its  own  resources.  These  entries  are  required  for 
the  current  simulated  analyst  system.  No  further  mention  will  be 
made  of  this  subsystem.  More  details  may  be  obtained  from 
references  1 and  m. 

b.  Message  Scheduling 

Message  scheduling  will  be  performed  via  RSX  realtime  services 
and  messages  will  be  forwarded  via  TISFIL  to  the  SSB  message 
distribution  module. 

c.  Scenario  Modification  and  Status  Information 

These  control  processor  functions  will  remain  largely  intact. 
They  include  message  review,  log  review,  message  addition,  message 
modification,  message  delivery  time  alteration,  message  deletion, 
and  exercise  termination. 

d.  Logging 

Disk  and  physical  device  (optional)  logging  will  be  continued. 
Log  entries  contain  time,  source,  and  function  dependent  data. 
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e.  Message  Interpretation 


At  present,  automated  evaluation  (decision  analysis)  is 
simplified  by  rigid  analyst  action  specifications  i.e.,  a pre- 
defined menu  of  actions.  There  is  a somewhat  similar  SSB  counter- 
part which  is  exemplified  in  the  menu  task.  However,  the  point 
at  which  AIPERS  will  receive  responses  is  after  all  applications 
tasks  have  been  requested  and  finished  intelligence  is  forwarded. 
Thus,  decision  analysis  will  be  based  on  keyword  analysis  and 
elapsed  time. 

3.3  Inputs/Outputs 

Inputs  and  outputs  are  of  two  types,  files  and  interactive  dialog. 
Listed  below  are  each  major  function  with  the  associated  inputs,  outputs, 
and  stored  elements. 

a.  Message  Scheduling  and  Scenario  Modification 

Inputs  consist  of  two  disk  files,  a hierarchical  message 
file  called  the  Message  and  Resource  file  (MSGKLS)  and  the  associ- 
ated index  file,  which  additionally  contains  run-time  status, 
called  the  message  time  list  (MTL) . These  fil..o  3re  initially 
produced  by  the  Scenario  Generation  Subsystem  and  updated  by 
the  control  processor  as  scenario  modifications  tre  requested. 

The  resulting  output  is  simulated  messages  which  are  forwarded 
in  a broadcast  fashion  to  users.  Additionally  a message  log 
file  (MSGLOG)  is  constructed  and  maintained.  Its  contents 
reflect  the  users  message  sequence. 

Interactive  inputs  include  requests  for  message  rext  or 
sequence  changes,  status  request  and  initial  exercise  definition 
parameters.  Interactive  outputs  include  corresponding  request 
acknowledgments,  error  displays,  and  status  displays. 

b.  Logging  and  Message  Interpretation 

Inputs  are  in  the  logical  form  of  finished  user  intelligence 
and  control  processor  action  summaries.  The  physical  input  is 
an  ICM  service  request  block  (SRB)  with  information  sufficient 
to  locate  the  appropriate  logical  input.  For  example,  the  user 
analyst  input  is  an  SRB  forwarded  by  the  terminal  gateway  and 
message  distribution  module  which  contains  the  message  sequence 
number  (MSN)  to  access  the  finished  message.  The  log  file 
(ALLLOG)  and  an  optional  corresponding  hard  copy  listing  contains 
the  action  summaries  with  elapsed  time  in  chronological  order. 
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Additionally,  an  exerci-.e  su'.nmary  is  maintained  based  on  analysis 
of  user  analyst  messages.  This  is  in  the  form  of  a control  team 
TTDL  screen  area  and  contains  recent  events,  time,  and  user  eval- 
uation for  each  user  analyst.  If  necessary,  the  message  file 
will  be  referenced  for  response  prediction  data. 

3.4  Data  Characteristics 

The  characteristics  of  all  files  are  detailed  in  Figure  A-5. 

All  files  are  presently  on  disk.  Assuming  an  average  scenario  of  50  messages, 

approximately  100,000  characters  of  storage  are  required.  The  capacity  of 
any  present  disk  (cartridge  or  multiplatter)  is  therefore  sufficient. 

Since  SSB  requires  a multiplatter  disk,  unless  site  constraints  dictate 
otherwise  the  AIPERS  files  will  be  maintained  on  that  device. 

The  present  anticipated  response  array  used  in  decision  analysis 

will  probably  be  replaced  with  a set  of  keywords  (dictionary)  and  an  associ- 

ated evaluation  indicator.  Some  research  will  need  to  be  performed  before 
the  exact  nature  of  the  SSB  decision  analysis  can  be  formulated. 

3.5  Failure  Contingencies 

The  system  is  not  of  a critical  nature.  Therefore,  no  back-up  or 
fallback  system  will  be  considered.  To  some  extent  the  current  simulation- 
based  AIPERS  can  be  considered  a back-up  or  fallback  system,  suitable  for 
training  in  crisis  management. 

Restart  facilities  are  currently  present  to  some  extent  in  both 
SSB  and  AIPERS.  These  will  be  retained.  Both  SSB  and  AIPERS  maintain  system 
status  on  disk  files. 
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SECTION  4.  EQUIPMENT/ SUPPORT  SOI  TWARE  ENVIRONMENT 

4.1  Equipment  Environment 

The  equipment  requirements  are  described  in  Section  2.4. 

4.2  Support  Software  Environment 

Support  software  is  divided  into  two  categories:  development  and 
operations.  The  operating  system  for  both  development  and  operations  is 
DEC  RSX-11D  version  6B. 

a.  Development  Software 

1.  MACRO-1 l Assembler 

2.  FORTRAN  IV  Plus  compiler 

3.  Standard  DEC  utilities 

4.  Biomac  - Structured  Language  macros 

b.  Operations 

1.  TOSS  Information  Management  System  (TIMS)  - Used  for 
hierarchical  file  access 

2.  TOSS  File  Support  - Used  for  flat  file  access 

3.  Intertask  Communication  Module  (ICM)  - Subexecutive 
used  for  memory  sharing  and  task  communications  both  with  SSB 
and  internally  (within  AIPERS). 

4.  Terminal  Transparent  Dipslay  Language  (TTDL)  - Used 
for  interactive  terminal  communication. 

5.  SSB  release  III 


4.3  Interfaces 

As  mentioned  earlier,  the  AIPERS  SSB  on-line  system  will  interface 
with  the  AIPERS  scenario  generation  subsystem  via  two  files:  The  Message  File 
and  the  time  list  file.  Both  are  described  in  Section  3.3.  Correspondingly 
the  interface  to  any  post-exercise  subsystem  (as  for  evaluation)  is  via 
files,  the  log  file  and  the  modified  message  file  (see  Section  3.3). 

The  primary  interface  of  interest  is,  of  course,  with  the  SSB 
system.  As  a receive  gateway  the  AIPERS  control  processor  will  forward  a 
service  request  block  (SRB)  to  the  message  distribution  module  via  RTMR/RSTA 
ICM  calls.  Imbedded  in  the  SRB  will  be  the  message  sequence  number  (MSN) 
for  the  previously  stored  TISFIL  message. 


As  a send  gateway  AIPERS  will  receive  an  SRB  from  MDM  and  forward 
an  acknowledgment  to  the  accounting  module  (TISAFM)  in  the  form  of  an  SRB. 
Again,  the  SRB  will  contain  the  MSN  for  the  finished  user  message. 

The  format  of  all  messages  is  TISS  Common  Format  (TCF) , in  which 
may  be  imbedded  network  information.  Figure  A-6  details  the  previously 
described  interfaces. 

4.4  Security 

It  is  envisioned  that  AIPERS  will  be  available  to  unclassified 
personnel.  At  present,  neither  the  system  nor  the  message  file  contains 
any  classified  information.  The  BUILD  function  allows  specification  of 
classification  level,  compartment,  and  handling.  If  necessary,  this 
information  can  be  used  to  secure  classified  information. 


Figure  A-6 . AIPERS/SSB  Interface 


SECTION  5.  COST  FACTORS  AND  OPTIONS 


Some  factors  which  may  constrain  operational  system  utilization 
are  listed  below. 

5.1  System  Documentation 

At  present  no  user  documentation  exists  for  the  AIPERS  scenario 
generation  subsystem.  Also,  no  formal  maintenance  documentation  exists. 
Although  the  scenario  generation  subsystem  is  not  directly  considered  as 
part  of  the  proposed  system,  it  is  an  obvious  prerequisite  operationally. 

5.2  Message  Editing 

The  present  control  processor  text  editor  is  barely  adequate. 

With  additional  effort  the  multiuser  SSB  text  editor  could  be  incorporated 
in  the  control  processor. 

5.3  Evaluation 

No  manual  or  automated  procedures  have  been  established  for 
exercise  evaluation  beyond  a very  limited  decision  analysis  capability.  It 
would  enhance  system  utility  to  provide  both  automatic  exercise  evaluation 
and  comprehensive  exercise  planners  guide.  The  automated  procedures  would 
permit  multiple  exercise  correlation  and  statistics  and  general  performance 
data. 


In  order  to  evaluate  effectively  particuladv  during  the  exercise, 
some  goals  and  evaluation  criteria  must  be  specified  prior  to  the  exercise. 
So,  a more  comprehensive  scenario  generation  subsystem  would  assist  in 
developing  clearly  goal -driven  exercises. 

5.4  System  Interference 

Only  a very  limited  amount  of  research  has  been  performed  to 
determine  the  degree  to  which  exercise  traffic  should  be  allowed  to  enter 
conventional  channels.  Likewise,  the  procedures  to  separate  exercise  from 
conventional  traffic  have  not  been  developed.  As  an  example,  should  an 
exercising  analyst  be  permitted  to  make  an  actual  DIAOLS  query  in  response 
to  an  exercise  message?  More  research  should  be  performed. 

5.5  Application  Software  Exercising 

In  previous  contracts  (AIPERS  R&D)  exercise  system  design  concepts 
and  techniques  were  developed,  which  provide  a means  of  simulating  one 
component  of  a transaction  processing  system,  i.e.,  external  analyst 
resources.  AIPERS,  as  currently  developed  in  a demonstration  prototype, 
consists  of  four  major  functional  components:  a means  of  preparing  and 
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disseminating  a scenario  of  messages;  a control  capability;  a logging  facil- 
ity; and  a user  analyst  interface  for  stand-alone  development.  With  the 
exception  of  the  user  analyst  interface,  all  of  the  above  functional  com- 
ponents are  required  in  a software  exercise  system;  a means  of  preparing 
and  disseminating  the  normal  dialogue  between  the  simulated  source  and 
the  host  system  is  required;  control  is  required  because  of  the  possibility 
of  failures  in  prerequisite  actions;  and  a tracking  mechanism  is  required 
for  compilation  of  non-automated  measurement.  In  addition,  an  adaptable 
target  system  interface  is  required  so  that  performance  measurements  can 
be  made. 


With  relatively  little  modification,  because  of  the  design  of  SSB 
with  a central  routine  mechanism  and  standard  gateway  interfaces,  the 
control  processor  developed  under  the  proposed  system  could  be  used  to 
test  new  gateways.  Particularly,  high-speed  and  peak-volume  loading  could 
be  tested  without  the  need  for  constructing  special  driver  programs. 
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SECTION  6.  DEVELOPMENT  PLAN 


The  plan  for  system  development  is  given  in  the  form  of  tasks, 
and  a GANTT  chart  indicating  deliverables  and  manpower  requirements  are 
presented  in  Figure  A-7. 

6.1  Tasks 


1.  Review  SSB  technical  documentation,  in  particular,  system/ 
subsystem  specifications,  installation  manual,  programmer  manual, 
and  users  guide. 

2.  Perform  an  SSB  system  generation  including  AIPERS  tasks  as 
Send  and  Receive  gateways. 

3.  Design  and  code  modifications  to  the  AIPERS  control  processor 
message  issuing  logic  so  that  it  conforms  to  SSB  receive  gateway 
procedures. 

4.  Design  and  code  modifications  to  the  AIPEi’.T  Publisher  so 
that  it  conforms  to  SSB  send  gateway  protocol. 

5.  Design  and  code  modifications  to  the  AIPERS  Publisher  to 
perform  decision  analysis  based  on  finished  messages  and  elapsed 
time. 


6.  Customize  the  present  scenario  to  provide  adequate  system 
testing,  then  integrate  and  test  the  system. 

7.  Demonstrate  the  system  in  actual  environment  conditions  to 
determine  training  effectiveness  and  measure  system  degradation. 


MISSION 
of 

Ram  Air  Development  Center 


RADC  plans  and  conducts  research,  exploratory  and  advanced 
development  programs  In  command,  control,  and  comnunlcatlons 


activities,  and  In  the  C3  areas  of  Information  sciences 


(C3) 

and  Intelligence.  The  principal  technical  mission  areas 
are  coianunicatlons , electromagnetic  guidance  and  control, 
surveillance  of  ground  and  aerospace  objects,  intelligence 
data  collection  and  handling,  information  system  technology, 
ionospheric  propagation,  solid  state  sciences,  microwave 
physics  and  electronic  reliability , maintainability  and 
compatibility . 
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